ARGUMENTS/REMARKS 



Claims 1-18 are pending. Claims 1, 5-8, 13, 17 and 18 were amended. 

The amendments are supported by the specification, for example in paragraphs [0006]- 
[0011] and [0066] of the application as published. No new matter was added. 

Rejection under 35 U,S,C. § 103 

Claims 1-18 were rejected under 35 U.S.C. § 103(a) as obvious in view of Webb et al. 
(U.S. Patent Pub. No. 2002/0083342) (hereinafter 'Webb") and Seki (U.S. Patent Pub. No. 
2003/0018753) (hereinafter "Sel^i"). It is respectfully submitted that the claims are not obvious 
for at least the following reasons. 

These rejections and the associated assertions of the Office Action are respectfully 
traversed. However, in order to expedite the prosecution of this application, all of the 
independent claims have been amended to more clearly distinguish the art relied upon. By way 
of example, claim 1 has been amended to recite: 

receiving a selection request from the remote user; 

receiving content from the device one or more devices on the home 
network u sing a content protocol[[,]] and without accessing a web server: wherein 
the content or services includes one or more of photos, music, documents, videos, 
games, or video or image data from one or more Internet cameras; and 

providing content or services to the remote user according to the 
selection request, wherein the receiving, verifying, generating and 
providing are performed by one or more devices of the home network. 

Requiring each device in a home network to include a Web server in order to share 
content would present problems for a user of a home network, as noted in the present 
application: 

[0006] One possible way to allow the content to remain in the 
home, secure, and still allow Intemet users to access it, would be 
for the consumer to host his own web server, e.g., on a personal 
computer ("PC") in his or her home. However, this solution would 
have at least the following requirements: (1) a dedicated PC 
running web server software; (2) an Intemet gateway that supports 
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network address translation ("NAT") and a firewall, and (3) the 
expertise to install and configure this equipment and servers, 

[0007] All of these requirements are potentially problematic for a 
typical user. The last requirement is beyond the expertise of the 
vast majority of consumers. 

(Emphasis Added). 

Other drawbacks of requiring a user of a home network to host a web server on a device 
in a home network are described in the present application as follows: 

[0008] Although the gateway provides the ability for mul- 
tiple devices/PCs to gain access to the Internet, the devices/ 
PCs are hidden in the home network from the Internet. If a 
consumer wants to share content from a PC/device behind 
the gateway to remote Internet users, the tasks of configuring 
the gateway properly to do port forwarding through NAT, 
which deals with mapping a selected port or protocol to a 
particular PC/device, and configuring the firewall to allow 
access to this PC on the home network, would be quite 
daunting for the casual consumer. The consumer would also 
need to install and configure the necessary servers on the 
PC/device to share the appropriate content. 

[0009] The content would need to reside on a dedicated 
web server device and this device would need to remain on 
at all times. In order to secure the content on the web server, 

the web server would need to use authentication, which the 
consumer would need to configure with usernames and 
passwords. However, this database of usernames and pass- 
words is usually only for a single device. It is not a common 
database used by all devices/PCs in the home network. 



Because of these drawbacks of the prior art, some implementations described in the 
present application allow a device in a home network to share content without requiring the 
device to run a web server: 
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[0011] Method and devices are provided for to simplify, 
for the user of a home network, the sharing of content with 
remote users. Some such implementations allow remote 
users who have logged into the home network to have access 
to devices and services within the home network. Access to 
such content, devices and services may be controlled by 
running a content protocol client on the home network that 
handles file sharing. This content protocol client could be 
any suitable type known to those of skill in the art, such as 
Windows networking (smb), UPnP, etc. Alternatively, the 
content protocol client could be a proprietary content pro- 
tocol client. Some implementations of the invention provide 
solutions for sharing multiple devices within the home 
network in a grouping to a particular remote user who logs 
into the home network in a secure fashion. 

The specific examples of content protocols noted in paragraph 11 of the published 
application are now recited in claims 5 and 17. For example, claim 5 now recites: 

The computer-readable medium of claim 3, wherein the second protocol is 
one of Windows networking (smb) or UPnP a content protocol . 

The Office Action acknowledges that "Webb does not specifically disclose receiving 
content from one or more devices on the home network using a content protocol." (p. 4, 1. 1-2). 
Applicant agrees with this assessment of Webb. Nowhere does Webb disclose or suggest 
"receiving content from the device using a content protocol," as recited in claim 1. 

Further, Webb states that "Each of the devices connected to the private network 16 
includes an on-board Web server that allows a user to perform various configuration, trouble- 
shooting, and/or administrative functions with respect to the device." (f [0043]). Thus, each of 
the devices in Webb's private network is required to include an on-board Web server that uses 
HTTP to serve files that form Web pages. Accordingly, Webb also fails to disclose or suggest 
receiving content from a second device on the home network "receiving content from the device 
using a content protocol and without accessing a web server'^ as recited in claim 1. 

Seki fails to cure the deficiencies of Webb. First, Applicant respectfully submits that the 
Office Action has not shown that that Seki discloses or suggests receiving content from a device 
using a content protocol. The Office Action states: 
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Seki discloses receiving content from one or more devices on the 
home network using a content protocol. [ i.e. content data is 
transmitted and displayed on remote terminal ] [ Abstract; and 
paragraphs 0005, 0105 and 0111, 0132 and 0137 ]. 

(p. 4, 1. 3-5). 

The above-quoted passage of the Office Action seems to suggest that "receiving content 
from one or more devices on the home network using a content protocol" is analogous to 
"content data is transmitted and displayed on remote terminal" as described in the cited passages 
of Seki. Applicant disagrees for the following reasons. 

Content protocols include, for example, Windows networking (smb), UPnP, etc, as 
described in, for example, paragraph [0011] of the application. HTTP is different from a content 
protocol, as is made clear in for example, paragraph [0015] of the application. 

Paragraphs [0132] and [0137] of Seki, for example, which are cited in the above-quoted 
passage of the Office Action, make no mention of receiving anything using a content protocol. 
For example, paragraph [0132] of Seki relates to displaying a data file on the remote terminal. 
However, paragraphs [0131]-[0132] of Seki clarifies that the data file is transmitted using the 
HTTP protocol, which is not a content protocol, as discussed above. As another example, 
paragraph [0137] of Seki states that "The remote terminal displays the received data file on the 
display using the Web browser (ST415)." However, paragraphs [0136]-[0138] of Seki clarify 
that the remote terminal communicates with the proxy server using the HTTP protocol, which is 
not a content protocol, as discussed above. Thus, paragraphs [0132] and [0137] of Seki do not 
disclose or suggest "receiving content from the device using a content protocol," as recited in 
claim 1. 

Content may include, for example, "photos, music, documents, videos, data from Internet 
cameras, etc.," as described in paragraph [0005] of the application. "The amount of digital 
content to be shared by the home network may be in the terab3^es." [0005]). Transmitting 
control commands, as described in Seki, fails to disclose or suggest "receiving content from the 
device using a content protocol," as recited in claim 1. 

For example, paragraphs [0005], [0105], and [0111] of Seki, cited in the above-quoted 
passage of the Office Action, mention different protocols. However, these passages seem to 
relate to transmitting/receiving commands, not receiving content. For example, paragraphs 
[0006] -[0007] of Seki seem to relate to transmitting control commands using the protocols 
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mentioned in paragraph [0005]. Similarly, paragraphs [0105]-[0106] seem to relate to 
transmitting control commands using the protocols mentioned in paragraph [0105]. Paragraph 
[0111] of Seki states that "Command transmitting/receiving control section 22 assembles a 
control command corresponding to protocol (for example, IEEE 1394 or ECHONET) applied to 
the home network to which the home-network apparatus is connected." Thus, paragraphs [0005], 
[0105], and [0111] of Seki describe receiving conmiands, not content. Therefore, paragraphs 
[0005], [0105], and [0111] of Seki fail to disclose or suggest "receiving content from the device 
using a content protocol," as recited in claim 1. 

Therefore, although Seki does separately discuss receiving a document using the HTTP 
protocol and receiving control commands using different protocol, Seki fails to disclose or 
suggest "receiving content from the device using a content protocol," as recited in claim 1. 
(Emphasis Added). 

Moreover, Seki fails to disclose or suggest receiving content from the device using a 
content protocol "and without accessing a web server y'' as recited in claim 1. Instead, Seki 
discloses "a remote control proxy method and apparatus for remotely controlling controlled 
apparatus on a home network from an extemal network," as described in paragraph [0002] of 
Seki. 

As discussed above, Seki does disclose receiving a data file transmitted from a gateway 
using the HTTP protocol. However, since the data file described in Seki is transmitted using the 
HTTP protocol, the data file is received by accessing a web server on the device. Thus, the 
description in Seki related to receiving a data file fails to disclose or suggest receiving content 
"using a content protocol and without accessing a web server^'' as recited in claim 1. 

Seki also describes receiving, for example, a "control request," "commands," or "control 
contents" using different protocols (^ [0109], [0110], [0137]). However, there is no teaching or 
suggestion in Seki of receiving what would normally be considered "content" where the content 
is not received by accessing a web server. The application makes clear that "content may 
include, for example, "photos, music, documents, videos, data from Intemet cameras, etc." and 
that the amount of such content to be shared may be in the terabytes (^ [0005]). As discussed 
above, transmitting/receiving control commands is not the same as receiving content. 

Therefore, although Seki does discuss receiving a document using the HTTP protocol 
and receiving commands using different protocols, Seki fails to disclose or suggest receiving 
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content from the device using a content protocol "and without accessing a web server"'^ as 
recited in claim 1. 

Therefore, even if one of skill in the art would have been motivated to combine Webb 
and Seki (which has not been established and which Applicants do not admit), this combination 
would not disclose all elements recited in claim 1 . 

All other independent claims have been amended to recite features similar to claim 1 and, 
therefore, are not obvious for at least the reasons set forth above. The dependent claims include 
all of the elements of the independent claims on which they are based and, therefore, are not 
obvious for at least the reasons set forth above. Accordingly, it is respectfully requested that all 
rejections of the pending claims be withdrawn. 

CONCLUSION 

Applicants believe that all pending claims are allowable and respectfully request a Notice 
of Allowance for this application from the Examiner. Should the Examiner believe that a 
telephone conference would expedite the prosecution of this application, the undersigned can be 
reached at the telephone number set out below. 

The Commissioner is hereby authorized to charge any additional fees, including any 
extension fees, which may be required or credit any overpayment directly to the account of the 
undersigned. No. 50-4480 (Order No. CISCP347). 

Respectfully submitted, 

Weaver Austin Villeneuve & Sampson LLP 

/Roger S. Sampson/ 

Roger S. Sampson 
Reg. No. 44,314 

P.O. Box 70250 
Oakland, CA 94612-0250 
(510) 663-1100 
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